I read the question(s) as aimed at large software/hardware purchases rather than smaller purchase orders. In my interviews with school personnel as well as strategic planners in the business/banking communities, I obtained the following advice in the categories of: Vendor Selection (RFP / RFT) Vendor Assessment Due Diligence Contract Pricing / Licensing Legal
.
Vendor Selection:
You will usually find there are a large number of vendors that supply the kinds of technology you are after. Best way to whittle them down to the top 3-5 is via a RFP (Request for Proposal) or RFT (Request for Tender) process, or a combination of the two.
RFP's are usually sent to a large number of vendors and are fairly high level. You describe briefly what system you need, architecture requirements, vendor support, implementation timeframes, provide them with high level process maps and describe the main features you are looking for. Based on the responses (some won't bother responding) you can then make a determination at a high level as to who might best have a chance of suiting your needs.
You then select 3-5 vendors and invite them to partake in a restricted RFT process. This is where you describe in excruciating detail what you are looking for, timeframes for delivery, detailed process maps, request detailed particulars of their corporation structure / shareholdings, their support services, disaster recovery systems, number of staff, references from their clients, their proposed implementation plan - including project staff & escalation procedures & project governance, value-added services, pricing structure, solution architecture, hardware, connectivity architecture, matrix of compatibility against requirements (this should be highlighted upfront in their response).
Vendor Assessment:
A balanced scorecard weighting the crucial requirements against "nice to have" requirements should be used and many standards are readily accessible over the internet.
Scoring should also include on-site demonstrations of the system solution the vendor is proposing. This is to ensure that the proposed solution is not an "in development" solution but is already available solution with demonstrated success. Many vendor companies use potential new clients as an opportunity to fund their own "drawing board" development plans. Solutions like these should be avoided at all costs. You do not want to purchase a system that is still to go through User Acceptance Testing or Systems Integration testing. Of course this is always a management decision and you may wish to sign an agreement with a vendor to jointly develop a system, but this is a different process altogether.
Understanding the stability of a vendor is a vital piece of assessment. This is where a great deal of attention should be paid to the legal structure of the vendor, external shareholders, paid up capital, directorships etc. Some vendors spend thousands on flash presentations but behind the scenes there may be very little by way of systems support structure.
Workshops should be held between the vendor and the actual eventual business users (not just management) to agree the solution requirements and ensure it can meet the needs of the business.
Due Diligence:
The RFT process should have revealed a preferred partner to go forward with and contract negotiations should have commenced. During this period there needs to be a rigorous Due Diligence process completed prior to contract signing.
Due diligence includes visits to the vendors headquarters or place of business to assess: actual real life demonstrations of more detailed system functionality, review of the vendor support structure, validation of corporate structure, random testing of requirements through scenario modeling, meet & greet with project / implementation staff, implementation governance agreement, lower level pricing negotiations, licensing negotiations, ongoing support agreements, help-desk structure / access, future version release functionality / release dates and general validation of the RFT response by management.
Contract Pricing / Licensing:
Pricing & costs should be agreed as a lump sum and payment structured as follows:
20% payment on contract signing
10% payment on commencement of implementation
10% payment on agreement of functional specifications
10% payment on successful UAT (User Acceptance Testing) sign off
50% payment on delivery of system and conversion of data
A daily burn rate or penalty rate should be agreed up front. This is a penalty you charge the vendor for each day past the agreed "Go Live" date the implementation runs. Conversely a bonus structure should be negotiated for early successful delivery.
Licensing should form part of the overall price, and additional licence costs / conditions need to be agreed prior to contract signing.
Legal:
The largest risk with dealing with technology vendors is the risk of "vapor-ware". The solution MUST meet that which was described and signed off on after the RFT. Many vendors have "slick" solutions that look great but do not hold up under scale, multiple users, environment etc. The legal department of your organization must be heavily involved in the negotiation of the service contract and development of service.
Never sign the terms & conditions of the vendor. THEY must sign YOURS. Of course the finer details of the vendor's T's & C's can be incorporated into the eventual service contract.
Ongoing support / warranty / maintenance should be specified very clearly in the legal contract.
Jurisdiction of the contract should be under the laws and statutes of the country where YOU reside - Not the Vendors home country.
General Summary:
There are many technology vendors in the market and their marketing budgets are HUGE. They spend a fortune on presentations that look slick but as always the devil is in the detail. Selection of a suitable vendor takes time and a large cost investment by the school or business. Nothing is worse than getting halfway through development only to find a gap in functionality that requires more external solutions or contracting of IT staff to fix. The typical IT joke is that whatever your spend budget is then triple it. And whatever your go live date is then add another quarter (3 months) on top of it. Technology vendors will ALWAYS tell you that they can do it - whatever you want they can do it. The responsibility for proving this lies largely with the business acquiring the product. Don't underestimate your due diligence process and be wary of vendors who suggest their solution is an easy installation. There is no such thing.
Also in regards to the RFT - it's a "garbage in / garbage out" situation. You need to be painfully clear and excruciatingly detailed in your requirements. The best way to do this is to map every process to how it should look or the desired state, get broad business sign off of each step in the process, review the sign off with your finance department to ensure all financial bases are covered and agree on the "to be state" before you build your RFT. This then becomes an input to the RFT and the more detail you provide the vendor the more chance you have of getting an accurate feel for their ability to meet your needs.
Typically for a total systems solution you should allow the vendors invited to the RFT process a minimum of 3 weeks to respond to your RFT.
I read the question(s) as aimed at large software/hardware purchases rather than smaller purchase orders. In my interviews with school personnel as well as strategic planners in the business/banking communities, I obtained the following advice in the categories of:
Vendor Selection (RFP / RFT)
Vendor Assessment
Due Diligence
Contract Pricing / Licensing
Legal
.
Vendor Selection:
Vendor Assessment:
Due Diligence:
Contract Pricing / Licensing:
- Pricing & costs should be agreed as a lump sum and payment structured as follows:
20% payment on contract signing10% payment on commencement of implementation
10% payment on agreement of functional specifications
10% payment on successful UAT (User Acceptance Testing) sign off
50% payment on delivery of system and conversion of data
Legal:
General Summary:
There are many technology vendors in the market and their marketing budgets are HUGE. They spend a fortune on presentations that look slick but as always the devil is in the detail. Selection of a suitable vendor takes time and a large cost investment by the school or business. Nothing is worse than getting halfway through development only to find a gap in functionality that requires more external solutions or contracting of IT staff to fix. The typical IT joke is that whatever your spend budget is then triple it. And whatever your go live date is then add another quarter (3 months) on top of it. Technology vendors will ALWAYS tell you that they can do it - whatever you want they can do it. The responsibility for proving this lies largely with the business acquiring the product. Don't underestimate your due diligence process and be wary of vendors who suggest their solution is an easy installation. There is no such thing.
Also in regards to the RFT - it's a "garbage in / garbage out" situation. You need to be painfully clear and excruciatingly detailed in your requirements. The best way to do this is to map every process to how it should look or the desired state, get broad business sign off of each step in the process, review the sign off with your finance department to ensure all financial bases are covered and agree on the "to be state" before you build your RFT. This then becomes an input to the RFT and the more detail you provide the vendor the more chance you have of getting an accurate feel for their ability to meet your needs.
Typically for a total systems solution you should allow the vendors invited to the RFT process a minimum of 3 weeks to respond to your RFT.